System and method for approving transactions

ABSTRACT

In a transaction between a merchant and a payer, approval of the transaction may be provided by a payment processing system using authentication information provided from a mobile device of the payer. The authentication information may include a location of the payer mobile device which may be compared to a location of a merchant payment device such that the transaction is approved if the payer mobile device is within a defined distance of the merchant payment device.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a divisional of U.S. application Ser. No.12/629,937, filed on Dec. 3, 2009, now pending, the disclosure of whichis herein incorporated by reference in its entirety.

FIELD OF THE INVENTION

This disclosure relates to systems and methods for approving commercialtransaction such as transactions between a merchant and a payer. Inparticular, though not exclusively, the disclosure relates totransactions involving credit cards, debit cards, and the like.

BACKGROUND OF THE INVENTION

With the exception of cash transactions, most commercial transactionsbetween a merchant and a customer typically use some form of paymentidentification device such as a credit card, debit card, loyalty card,or the like. Such transactions require approval by the administrator orprovider of the payment identification card. Approval may be provided byvarious means such as a personal identification number, password, orpresence of a physical payment authorization device (e.g., credit card).These solutions don't deal effectively with some classes of fraud, suchas counterfeit credit cards, and use of a real card using a fraudulentmerchant account. In particular, a person frequently traveling toforeign countries must either notify the institution issuing the cardbefore every trip or forgo the crude default protection of disallowingtransactions originating in a foreign country.

What is required is an improved system and method for identifyingfraudulent attempts to use a payment authorization device based on thelocation of the device.

SUMMARY OF THE INVENTION

In one aspect of the disclosure, there is provided a method forapproving a transaction between a merchant payment device of a merchantand a payer identification device of a payer. The method comprisesidentifying the payer from the payer identification device at themerchant payment device, identifying a mobile communications device ofthe payer, communicating with the mobile communications device toreceive a communication from the mobile communications device whichindicates authentication data, and determining an approval for thetransaction from the authentication data.

In one aspect of the disclosure, there is provided a payment processingsystem for approving a transaction between a merchant payment device ofa merchant and a payer identification device of a payer. The paymentprocessing system may be configured to receive a transaction record thatindicates the payer identification device and the merchant paymentdevice. The payment processing system may also be configured to analyzeauthentication data from a mobile communications device of the payer,approve the transaction using the authentication data, and indicate theapproval of the transaction to the merchant payment device.

In one aspect of the disclosure, there is provided a computer-readablemedium comprising computer executable instructions for execution by aprocessor of a device, that, when executed, cause the processor to reada payment identification device of a payer, identify a mobilecommunications device of the payer, request authentication informationfrom the mobile communications device, receive the authenticationinformation from the mobile communications device, generate atransaction record incorporating the authentication information, andprovide the transaction record to a payment processing system.

BRIEF DESCRIPTION OF THE DRAWINGS

Reference will now be made, by way of example only, to specificembodiments and to the accompanying drawings in which:

FIG. 1 illustrates components of a transaction system of the presentdisclosure;

FIG. 2 illustrates a method for approving a transaction;

FIG. 3 illustrates a method for approving a transaction using locationdata of a payer mobile device;

FIG. 4 illustrates a method for approving a transaction usingtransaction history known to a payer mobile device;

FIG. 5 illustrates a payment processing system process;

FIG. 6 illustrates a processor and memory of a merchant payment devicein communication with a processor and memory of a payment processingsystem; and

FIG. 7 illustrates an instruction set for executing on the merchantpayment device processor of FIG. 6.

DETAILED DESCRIPTION OF THE INVENTION

A system 10 in accordance with an embodiment of the disclosure isillustrated in FIG. 1. In the system 10, there is provided a paymentprocessing system 12 that interacts with a merchant payment device 14through known communications protocols such as TCP/IP, FTP, EFTPOS etc.During a transaction, a payer, e.g., a customer, may identify a payeridentification device 16 to the transaction. The payer identificationdevice may be a credit card, debit card, or other form of accountidentifier, which in some embodiments, may include a mobiletelecommunications device. The merchant payment device 14 (e.g., acredit card reader, a Bluetooth radio) is able to extract from the payeridentification device 16 sufficient information, e.g., account number orcard number, to pay the merchant. The merchant payment device 14 maycommunicate the payer information to the payment processing system 12for verification. The payment processing system 12 may include adatabase 13 which stores payer identification including payer name,contact details, account information, credit limit and other requiredinformation for verifying transactions of the payer. In any typicallegitimate transaction between the payer and the merchant, a mobiletelecommunications device 18 of the payer will be available. In anembodiment of the disclosure, the ubiquitous nature of mobile devices istaken into account so that the payer's mobile device can be used in thetransaction as an additional verification tool.

A method for verifying a transaction using a payer's mobile device isshown in the, flowchart 100 of FIG. 2. At step 101, the merchant paymentdevice 14 scans, reads or otherwise identifies the payer identificationdevice 16. At step 102, a mobile communications device 18 of the payeris identified, e.g., from data associated with the payer identificationdevice 16, or from other data provided at the transaction, e.g., bycommunication direct from the payer. The merchant payment device 14contacts the payer mobile device 18 to request authentication data (step103) which is received at step 104. The authentication data is then usedto determine an approval for the transaction (step 105), e.g., byproviding the authentication data to a payment processing system 12.

The authentication data may take several forms, including the locationof the payer mobile device or previous transaction history of the payer,known to the payer mobile device, which may or may not be known to themerchant payment device.

The authentication data may be provided from the payer mobile device tothe payment processing service or to the merchant payment device and viaany necessary intermediaries such as routers, network providers and thelike.

The method described in FIG. 2 may be used to tie validation andauthorization of a payment transaction to the locations of the entitiesinvolved. That is, the method may extend transaction authorization toinclude geolocation information. If the payer identification device 16(credit card, debit card, cell phone acting as a credit card, etc.) ispresent, the geolocation of the payer mobile device 18 is comparedduring the card processor's authorization processing to othergeolocation information, such as the location of the merchant's store,to establish that the person authorized to execute the transaction is inapproximately the same location as the payer identification device 16.In simple terms, if the authorized card holder isn't near the cardreader, the transaction should either be declined or additional identityconfirmation should be conducted.

In one embodiment, illustrated in the flowchart 200 of FIG. 3, themerchant payment device 14 may be used to read the payer identificationdevice 16 to pay a merchant (step 201).The merchant payment device 14sends to the payment processing system 12 a transaction record (step202) which identifies the payer identification device 16, the merchantpayment device 14 and other details of the transaction such as theamount, time, etc. The transaction record maybe used to determine ageolocation of the merchant payment device (step 203). In oneembodiment, the location of the merchant payment device 14 may be knownlocally in the payment processing system 12, e.g., stored in a localdatabase 13, and may be retrieved from the database 13 using an identityof the merchant or the merchant payment device 14. In an alternativeembodiment, in particular where the merchant payment device 14 may bemobile, the transaction record may include the geolocation of themerchant payment device 14, e.g., as determined by an internal GPSsystem of the merchant payment device 14 or other location determinationsystem.

At step 204, the merchant payment device 14 may identify the mobilecommunications device 18 and request the current location of the mobilecommunications device 18 (step 205) which is received at step 206 andadded to the transaction record. In an alternative embodiment, thedatabase 13 of the payment processing system 12 may store contactdetails for the mobile communications device 18 such that steps 204,205, 206 are performed by the payment processing system once the payerhas been identified from the transaction record.

In one embodiment, the payer mobile device 18 may provide locationinformation without user input. In an alternative embodiment, a message,such as an SMS message may be sent to the payer's mobile device 18,requiring an SMS response from the payer, with the location of the payermobile device 18 being extracted from the response SMS message. If thepayer mobile device 18 is within an acceptable distance from thelocation reported by the merchant payment device 14, the merchantpayment device 14 is sent a message approving the transaction (step207). The acceptable distance may depend on the transaction environment.For example, transactions with merchants where the payer may often be ina car, such as in a drive-through premises, may allow a greater distancethan transactions where customers are generally slower or morestationary. Typical allowable distances are considered to be 100 feetfor a casual restaurant, 20 feet for a retail store, and 10 feet for afast food restaurant. The typical distance for each merchant is storedin the Payment Processing Service database 13.

In one embodiment, the transaction record may be complete when firstsent from the merchant payment device 14 to the payment processingsystem 12. This has the advantage that a location of the mobilecommunications device 18 and the merchant payment device 14 are known atthe immediate time of the transaction. However, the transaction recordmay also be sent in multiple stages. For example, the payment processingsystem 12 may separately query the merchant payment device 14 for itscurrent location, which the merchant payment device 14 may add to thetransaction record in response to the query.

In one embodiment illustrated in the flowchart 300 of FIG. 4, themerchant payment device 14 is used to read the payer identificationdevice to pay a merchant (step 301). The merchant payment device 14looks for the payer mobile device 18 (step 302) (e.g., cell phone, PDA,MID, etc.) and connects to the payer mobile device 18 (step 303), whichcommunicates a previous transaction history, such as an authenticationhistory for the merchant payment device 14 (step 304). If the payermobile device 18 is not present or the registration check fails, thetransaction requires additional verification before being accepted. Themerchant payment device 14 sends the transaction record to the paymentprocessing service 12 indicating that the payment processing system 18can verify the transaction (step 305) by contacting the payer mobiledevice 18 using the process illustrated in FIG. 3 (from step 203). Ifthe merchant payment device 14 verifies at step 304 that the payeridentification device 16 has been previously authorized by the payermobile device 18 for the merchant, the merchant payment device indicatesthe authorization history in the transaction record to the paymentprocessing service. The payment processing service 12 processes thetransaction, include checking the authorization history. If thevalidations succeed, the payment processing service 12 sends to themerchant payment device 14 a message approving the transaction (step308). In embodiments such as this, e.g., where independent locationverification is not necessarily used in the authentication step, it isconceivable that the payment identification device 16 and the payermobile device 18 may be merged into a single device.

In one embodiment, the mobile communications device may provideadditional authentication information that is unknown to the merchantand/or the merchant payment device for independent verification in thepayment processing system. When the merchant payment device 14 queriesthe payer mobile device 18 for the payer mobile device's authenticationinformation, in addition to providing the payer mobile device's mostrecent location, the payer mobile device 18 may also include informationabout the previous transaction, if any, involving the payeridentification device 16. For example, the encrypted authenticationinformation might include one or more of the geolocation, timestamp,merchant identity or transaction amount of the previous transaction,which is data the merchant is unlikely to possess and which ties theauthentication information to the current transaction. The payer mobiledevice 18 returns the authentication data to the merchant payment device14 in an encrypted form not decipherable by the merchant payment device14. The merchant payment device 14 sends to the payment processingsystem 12 a transaction record that includes the geolocation of themerchant payment device 14 and the encrypted authentication informationprovided by the payer mobile device. The process at the paymentprocessing end is shown in the flowchart 400 of FIG. 5. At step 401, thepayment processing service 12 receives the transaction record anddecrypts the authentication data provided by the payer mobile device 18(via the merchant payment device 14) (step 402). The payment processingsystem 12 may verify the authentication data within the paymentprocessing system (step 403), for example by retrieving details of theprevious transaction from the database 13 and comparing the details withthe data provided in the transaction record. In one embodiment, theprevious transaction history may be sufficient to approve thetransaction, without using the location data (step 404). Alternatively,the location data may also be such that if the payer mobile device 14 iswithin the defined acceptable distance from the location reported by themerchant payment device 14, then the payment processing system 12 mayindicate to the merchant payment device 14 that the transaction isapproved. Otherwise, if the authentication data fails these or othertests the payment processing service 12 may require additionalverification before being accepted. By providing additional encryptedauthentication information unknown to the merchant payment device 14 andincorporating the encrypted data in the transaction record, the systemcan reduce the possibility of replaying the encrypted authenticationinformation which may lead to false or fraudulent approval of thetransaction.

In one embodiment, the encrypted authentication data provided by thepayer mobile device 18 may be supplemented by additional encrypted datafrom the payer identification device 16. For example, a payeridentification device 16 may be provided with geolocation capabilities,such as from an internal GPS receiver which can be provided to themerchant payment device 14 during a transaction. To reduce thepossibility of replaying the encrypted authentication information,merchant payment device sends to the transaction processor a transactionrecord that includes the encrypted authentication information providedby the payer identification device 16, and the encrypted authenticationinformation provided by the payer mobile device 18. The paymentprocessing service 12 processes the transaction record, includingdecrypting the authentication data provided by the payer identificationdevice 16 and payer mobile device 18. If either the payer identificationdevice 16 or the payer mobile device 18 is outside the acceptabledistance from the location reported by the merchant payment device 14,or the authentication data fails some other test, the payment processingservice may seek additional verification before approving thetransaction. If the payment processing service 12 checks succeed, thepayment processing service 12 sends to the merchant payment device 14 amessage approving the transaction.

The components of the system 10 may be embodied in hardware, software,firmware or a combination of hardware, software and/or firmware. In ahardware embodiment, a merchant payment device may include a processor61 operatively associated with a memory 62 as shown in FIG. 6. Thememory 62 may store an instruction set 500 executable by the processor61. When executed, the instruction set 500, shown in FIG. 7, causes theprocessor to commence a transaction by reading a payment identificationdevice of a payer (step 501). After identifying a mobile communicationsdevice of the payer (step 502), a request for authentication informationis sent to the mobile communications device (step 503) with theauthentication information being received from the mobile communicationsdevice at step 504. The processor 61 then generates a transaction recordincorporating the authentication information (step 505) and provides thetransaction record to a payment processing system (step 506) forsubsequent approval.

As shown in FIG. 6, the processor 61 of the merchant device maycommunicate the transaction record to a processor 68 and associatedmemory 69 of the payment processing system 12 through a suitablecommunications link 65. In addition, the processor 61 of the merchantdevice and/or the processor 68 of the payment processing system 12 maycommunicate with a processor and memory of a PayerMobile Device (notshown), for retrieving the required authentication information.

Embodiments of the system described above can be used to improveauthorization confidence for a significant fraction of credit card uses,i.e., when the cardholder presents the physical card to a merchant andfor other forms of payer identification devices. Thus, the system may beused to reduce credit card fraud by reducing the successful use ofstolen credit cards, cloned credit cards, or fraudulent merchant cardreaders.

Although embodiments of the present invention have been illustrated inthe accompanied drawings and described in the foregoing description, itwill be understood that the invention is not limited to the embodimentsdisclosed, but is capable of numerous rearrangements, modifications, andsubstitutions without departing from the spirit of the invention as setforth and defined by the following claims. For example, the capabilitiesof the invention can be performed fully and/or partially by one or moreof the blocks, modules, processors or memories. Also, these capabilitiesmay be performed in the current manner or in a distributed manner andon, or via, any device able to provide and/or receive information.Further, although depicted in a particular manner, various modules orblocks may be repositioned without departing from the scope of thecurrent invention. Still further, although depicted in a particularmanner, a greater or lesser number of modules and connections can beutilized with the present invention in order to accomplish the presentinvention, to provide additional known features to the presentinvention, and/or to make the present invention more efficient. Also,the information sent between various modules can be sent between themodules via at least one of a data network, the Internet, an InternetProtocol network, a wireless source, and a wired source and viaplurality of protocols.

1. A method of identifying whether to complete a first transactionbetween a merchant and payer based on information about a seconddifferent transaction between the merchant and the payer, the methodcomprising: identifying, by a merchant payment device, the payer from apayer identification device; identifying, by the merchant paymentdevice, whether a mobile communication device associated with the payeris available; responsive to identifying that the mobile communicationdevice is available, requesting, by the merchant payment device, theinformation about the second different transaction between the merchantand the payer from the mobile communications device; identifying, by themerchant payment device, reply data from the mobile communication deviceresponsive to the requesting; verifying, by the merchant payment device,whether the reply data includes the information about the seconddifferent transaction between the merchant and the payer, wherein theverifying includes: generating a communication based on the reply data,wherein the communication includes encrypted information of the replydata; transmitting the communication to a payment processing system; andidentifying, by the merchant payment device, an approval of the firsttransaction between the merchant and the payer responsive to a result ofthe verifying.
 2. The method according to claim 1, wherein generating,by the merchant payment device, the communication based on the replydata further comprises: generating, by the merchant payment device, atransaction record including details of the first transaction betweenthe merchant and the payer; wherein the generated communication includesthe generated transaction record.
 3. The method according to claim 1,further comprising transmitting, by the merchant payment device, arequest for a location of the mobile communications device to the mobilecommunications device.
 4. The method according to claim 3, wherein thecommunication is generated based on location data received responsive tothe request for the location, and wherein the generated communicationincludes the location data.
 5. The method according to claim 1, whereingenerating, by the merchant payment device, the communication based onthe reply data further comprises: identifying, by the merchant paymentdevice, location data that represents a current location of the mobiledevice; and generating, by the merchant payment device, thecommunication based on the location data, wherein the generatedcommunication includes the location data.
 6. The method according toclaim 1, further comprising: determining, by the merchant paymentdevice, a location of the mobile communications device from an incomingtext message received from the mobile communications device; wherein thegenerated communication includes information about the location.
 7. Anon-transitory computer-readable medium having instructions storedthereon that, in response to execution by a processing device, cause theprocessing device to perform operations for obtaining an approval of afirst transaction between a merchant and a payer based on informationabout a second different transaction between the merchant and the payer,the operations comprising: identifying the payer from a payeridentification device; identifying whether a mobile communication deviceassociated with the payer is available; responsive to identifying thatthe merchant payment device is available, requesting the informationabout the second different transaction between the merchant and thepayer from the mobile communication device; identifying reply data fromthe mobile communication device responsive to the requesting; verifyingwhether the reply data includes the information about the seconddifferent transaction between the merchant and the payer, wherein theverifying includes: generating a communication based on the reply data,wherein the communication includes encrypted information of the replydata; and transmitting the communication to a remote device; andidentifying the approval of the first transaction between the merchantand the payer responsive to a result of the verifying.
 8. Thenon-transitory computer-readable medium according to claim 7, whereingenerating, by the merchant payment device, the communication based onthe reply data: generating, by the merchant payment device, atransaction record including details of the first transaction betweenthe merchant and the payer; wherein the generated communication includesthe generated transaction record.
 9. The non-transitorycomputer-readable medium of claim 7, wherein the operations furthercomprise transmitting, by the merchant payment device, a request for alocation of the mobile communications device to the mobilecommunications device.
 10. The non-transitory computer-readable mediumof claim 9, wherein generated communication includes location datareceived responsive to the request for the location of the mobilecommunication device.
 11. The non-transitory computer-readable medium ofclaim 7, wherein the generated communication includes information abouta location of the mobile communication device.
 12. The non-transitorycomputer-readable medium of claim 7, wherein the operations furthercomprise: determining, by the merchant payment device, a location of themobile communications device from an incoming text message received fromthe mobile communications device; wherein the generated communicationincludes information about the location.